Method, system, and program for maintaining data in a distributed computing environment for processing transaction requests

ABSTRACT

Provided are a method, system, and program for processing a transaction. Transaction data is transmitted from one primary storage site to a plurality of secondary storage sites. A transaction request is received at one secondary storage site and processed to include transaction data from the secondary storage site that was transmitted from the primary storage site. The processed transaction request including transaction data is transmitted from the secondary storage site to the primary storage site to approve the transaction. The transaction request at the primary storage site is approved if the transaction data included in the received transaction request is consistent with the transaction data maintained at the primary storage site.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. patent application No.10/096,423, filed on Mar. 12, 2002, which application is incorporatedherein by reference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method, system, and program formaintaining data in a distributed computing environment for processingtransaction requests.

2. Description of the Related Art

In a common transaction model for Internet electronic commerce(e-commerce), a consumer retrieves Internet web pages (e.g., HypertextMarkup Language (HTML) pages, Extensible Markup Language (XML) pages,etc.) from a retailer's web site to select a product and then purchasethe product online, typically using a credit card number. The consumerwill retrieve one page, such as the product search and selection page,and select a product within the page displayed within a graphical userinterface (GUI), such as an HTML browser, and then submit the page backto the retailer web site. The retailer web site will then transmit pagesto the consumer's browser including fields where the consumer entersbilling and credit card information, which is then submitted back to theretailer's web site to process the transaction. The retailer Web sitewill typically confirm completion of the transaction to the consumer'sbrowser upon determining that there is sufficient inventory to fulfillthe purchase and verifying the provided credit card number.

One of the noticeable effects of the above e-commerce transaction modelis the transmission or network delays that occur when the data istransmitted back-and-forth between the consumer browser and the retailerweb site. Such delays increase as the distance between the retailer website and consumer also increases. The consumer oftentimes experiencesthis delay by having to wait for a submitted page including user enteredinformation to be received by the retailer web site and having to waitto receive the next page that is part of the transaction.

For these reasons, there is a need in the art for improved techniquesfor enabling remote transactions over a network, such as commercialtransactions.

SUMMARY OF THE PREFERRED EMBODIMENTS

Provided are a method, system, and program for processing a transaction.Transaction data is transmitted from one primary storage site to aplurality of secondary storage sites. A transaction request is receivedat one secondary storage site and processed to include transaction datafrom the secondary storage site that was transmitted from the primarystorage site. The processed transaction request including transactiondata is transmitted from the secondary storage site to the primarystorage site to approve the transaction. The transaction request at theprimary storage site is approved if the transaction data included in thereceived transaction request is consistent with the transaction datamaintained at the primary storage site.

In further implementations, the transaction request received at thesecondary storage site comprises a request to access resources. Adetermination is made from the transaction data at the secondary storagesite that was transmitted from the primary storage site as to whetherthe requested resource is available. A message indicating that therequested resource is not available is returned if the transaction dataat the secondary storage site indicates that the requested resource isnot available.

Yet further, the transaction request received at the secondary storagesite comprises a request to purchase a product. Determination is madefrom the transaction data at the secondary storage site that wastransmitted from the primary storage site of pricing information for therequested product. A response to return to a client originating thetransaction request indicating the pricing information for the requestedproduct is generated at the secondary storage site. The generatedresponse is transmitted to the client.

The described implementations provide techniques for propagating datafrom a primary site to secondary storage sites so that transactionrequests can be directed to the secondary storage site to handle. Withthe described implementations, the transaction requests are processed atthe secondary storage site with data transmitted from the primarystorage site. The processed transaction request is then submitted to theprimary site to approve the transaction to ensure that the transactiondata at the secondary storage site is consistent with that at theprimary storage site. In this way, many of the transaction processingoperations are performed at the secondary sites, which may be closer ingeographical proximity to the clients initiating the transactionrequests.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numbers representscorresponding parts throughout:

FIG. 1 illustrates a distributed computing environment in which aspectsof the invention are implemented;

FIGS. 2 a and 2 b illustrate additional distributed computingenvironments in which further aspects of the invention are implemented;

FIG. 3 illustrates a data structure for providing information on how topropagate data sets to secondary servers in accordance withimplementations of the invention;

FIGS. 4 and 5 illustrate logic to schedule data mirroring operations inaccordance with implementations of the invention;

FIG. 6 illustrates logic to process data requests in accordance withimplementations of the invention; and

FIGS. 7 and 8 illustrate logic to process a transaction request inaccordance with implementations of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following description, reference is made to the accompanyingdrawings which form a part hereof, and which illustrate severalembodiments of the present invention. It is understood that otherembodiments may be utilized and structural and operational changes maybe made without departing from the scope of the present invention.

FIG. 1 illustrates a distributed computing environment in which aspectsof the invention are implemented. A primary server 2 maintains aHypertext Transfer Protocol (HTTP) server 4 to respond to HTTP requestsfrom clients 6 a, 6 b . . . 6 n in geographical location A (8) andclients 10 a, 10 b . . . 10 n in geographical location B (12) over anetwork 14. The primary server 2 further includes transaction code 5 toprocess transaction requests as described below. The clients 6 a, 6 b .. . 6n and 10 a, 10 b . . . 10 n may include HTTP clients, such asHypertext Markup Language (HTML) browsers (not shown) to transmit HTTPrequests for information to the HTTP server 4. The network 14 maycomprise any type of network known in the art, such as a Wide AreaNetwork, the Internet, an Intranet, a Local Area Network (LAN), etc. Thegeographical locations A (8) and B (12) may be separated by asignificant geographical distance from geographical location C (16),which includes the primary server 2. For instance, the location C (14)may be separated by a distance of thousands of miles from locations A(8) and B (12), or on separate continents, different states, etc.

The primary server 2 is capable of accessing data from primary storage18, which includes database data 20, such as database tables, andcontent 22, such as textual information, multimedia content (e.g., audiofiles, movie files, images, etc.). The primary server 2 includes a datacopy program 24 capable of propagating data from the primary storage 18to secondary servers 30 a and 30 b at locations A (8) and B (12) tostore in secondary storages 32 a and 32 b, respectively. The secondaryservers 30 a and 30 b further include data copy programs 34 a and 34 b,respectively, to receive data from the primary server data copy program24 and store received data in the secondary storages 32 a and 32 b. Incertain implementations, the data copy program 24, 30 a, and 30 b maycomprise the International Business Machines Corporation (IBM) ExtendedRemote Copy (XRC) or Peer-to-Peer Remote Copy (PPRC) products thatensure that updates to a primary location are applied to a secondarylocation in real time. Alternatively, the data copy programs 24 a, 30 a,and 30 b may comprise any program capable of replicating data and dataupdates at a primary location to mirror sites. Although two secondarysites at locations A (8) and B (12) are shown, additional sites,including additional secondary servers and storages, may be incorporatedinto the distributed computing environment of the describedimplementations.

The secondary servers 30 a and 30 b further include HTTP servers 36 aand 36 b, respectively, to respond to HTTP requests from the clients 6a, 6 b . . . 6 n and 1Oa, 10 b . . . 10 n. The secondary servers alsoinclude transaction code 37 a and 37 b to process client requests in themanner described below. The secondary storages 32 a and 32 b includelocation specific database data 38 a and 38 b and location specificcontent 40 a and 40 b. The location specific data 38 a, 38 b, 40 a, and40 b are subsets of the data 20 and 22 maintained in the primary storage20 and 22. For instance, the primary storage 18 includes database data20 and content 22 for all geographical locations. The data routing map42 provides information on how data in the primary storage database data20 and content 22 maps to the location sites A (8) and B (12). The datacopy program 24 would access the data routing map 42 to determine whichsecondary server site to send data so that location A specific data issent to secondary server 30 a and location B specific data is sent tosecondary server 30 b.

In certain implementations, the clients 6 a, 6 b . . . 6 n and 10 a, 10b . . . 10 n would submit HTTP requests for data in the primary storage18 to the primary server 2 over network 14. The HTTP server 4 may thenredirect requests from the clients 6 a, 6 b . . . 6 n and 10 a, 10 b . .. 10 n to the secondary server 30 a and 30 b at the location that is thesitus of the originating client, i.e., requests from clients 6 a, 6 b .. . 6 n would be redirected to the secondary server 30 a at location A(8) and requests from clients 10 a, 10 b . . . 10 n would be redirectedto secondary server 30 b at location B (12). In certain implementations,because the secondary storages 32 a and 32 b maintain location specificdata, the secondary servers 30 a and 30 b can service requests from theclients 6 a, 6 b . . . 6 n and 10 a, 10 b . . . 10 n from locationspecific data.

In certain of the implementations, a portion of the data in thesecondary storages 32 a and 32 b may be common data maintained at allremote locations A and B, and other of the data at the remote sites maybe specific to the particular location. For instance, in implementationswhere the primary server comprises a retailer e-commerce commerce website, the database 20 may maintain customer account information, such asaddress and payment information, and inventory information. The content22 may maintain information on products and services provided by theretailer. The retailer would further maintain the secondary sites at thelocations A and B to service client requests from the secondary storagessystems within their geographic proximity. In this way, network relateddelays resulting from the processing of commercial communicationsbetween the clients 6 a, 6 b . . . 6 n and 10 a, 10 b . . . 10 n and theserver processing the transaction are minimized because the distance ofthe network transaction is reduced. The content 40 a and 40 b mayinclude the same data on the retailer products and services, and thusnot differ between geographical sites. However, the location specificdatabase data 38 a and 38 b may include information on only thoseclients 6 a, 6 b . . . 6 n and 10 a, 10 b . . . 10 n within thegeographical location of the secondary server 30 a and 30 b, such thatlocation A database data 38 a would include customer information forclients 6 a, 6 b . . . 6 n, and not clients 10 a, 10 b . . . 10 n, anddatabase data 38 b would include customer information for clients 10 a,10 b . . . 10 n and not clients 6 a, 6 b . . . 6 n.

In the implementation shown in FIG. 1, the clients 6 a, 6 b . . . 6 nand l0 a, 10 b . . . 10 n, secondary servers 30 a and 30 b, and primaryserver 2 communicate over a common network 14, such as the Internet orany other network known in the art. FIGS. 2 a and 2 b illustrate anadditional implementation where, as shown in FIG. 2 a, the primaryserver 102 and secondary servers 130 a and 130 b communicate over aprivate network 114, which may comprise any network limited toauthorized members of the organization, i.e., employees etc. The privatenetwork 114, may comprise a Wide Area Network (WAN), Storage AreaNetwork (SAN), Intranet, Local Area Network (LAN), Virtual PrivateNetwork (VPN), etc. Separately, as shown in FIG. 2 b, the clients 106 a,106 b . . . 106 n and 110 a, 110 b . . . 110 n, primary server 102, andsecondary servers 130 a and 130 b may communicate over a separatenetwork 116, such as the Internet. In this way, the primary server 102propagates data to the secondary servers 130 a and 130 b through aprivate network separate from the network the clients 106 a, 106 b . . .106 n and 110 a, 110 b . . . 110 n use to access the data.

Still further alternative distributed computing environments arepossible. For instance, in certain implementations, a separate networkmay exist between the clients 106 a, 106 b . . . 106 n and 110 a, 110 b. . . 110 n and the secondary servers 130 a and 103 b in a particulargeographical location, such as a Storage Area Network (SAN), Local AreaNetwork (LAN), etc. Yet further, the clients may communicate with thesecondary server within their geographical location through a commonsubnet of the Internet, such that each geographical location comprises aseparate subnet. Any other network architecture or arrangement known inthe art may also be used to connect the clients, primary server andsecondary servers.

As discussed, when propagating data to the remote secondary servers 30 aand 30 b, the primary server 2, and data copy program 24 therein may usea data routing map 42, or any other data structure, to determine how toroute data to the secondary sites. FIG. 3 illustrates an example in oneimplementation of the information the data routing map 42 would maintainfor each data set to be mirrored at a remote secondary site. The datarouting map 42 maintains an entry 200 for each data set to be separatelymirrored to one or more of the remote secondary servers 30 a and 30 b.Each entry 200 includes a data set information 202 indicating the datasets to be mirrored. The data set information 202 may indicate specificfiles, a directory, a database table, records in a database, etc. Incertain instances, the data set information 202 may indicate a query,such that all data in the database data 20 and/or content 22 satisfyingthe query is part of the data set to mirror. For instance, the query mayindicate a particular location, such that all database records havingthe location value, i.e., all customers within a particular geographicregion, form a data set to mirror to a particular server 30 a, 30 b.

Each entry 200 further indicates an update frequency 204 that specifieshow frequently data from a particular data set 202 is mirrored to theremote site. For instance, critical data, such as payment and addressinformation, inventory information, etc., may be immediately mirrored tothe remote sites, such that any updates to such critical data areimmediately copied to the remote site in real time. In this way, thesecondary storages 32 a and 32 b maintain the most recent updates forsuch critical data. In certain implementations, the data copy program 24may transfer updates to critical data immediately to the secondaryservers 30 a and 30 b when such updates are applied to the primarystorage 18, such that the update does not complete until the secondaryserver 30 a and 30 b acknowledges receiving the update. However, lesscritical data may be updated at less frequent intervals, such as once aday, etc. For instance, the retailer product advertising and pricinginformation may be mirrored only once a day as such data does notfrequently change. The target server information 206 indicates the oneor more secondary servers 30 a, 30 b to receive the data sets. Forinstance, data that is common among the geographical locations, such ascertain advertising and pricing information, may be propagated to allsecondary servers 30 a and 30 b, whereas geographical specific data maybe propagated to the one or more servers within that specific region.

FIG. 4 illustrates logic implemented in the data copy program 24 at theprimary server 2 to propagate updated data to the secondary servers 30 aand 30 b. At block 250, the data copy program 24 begins the process toschedule data mirroring operations. For each entry 200 (FIG. 3) in thedata routing map 42 that does not require real-time updates, the datacopy program 24 schedules (at block 252) a mirroring operation to occurat an interval equivalent to the specified update frequency 204 for theentry 200. The scheduled mirroring operation would indicate the data setentries 200 to include in the mirroring operation and the targetsecondary site(s). At block 260, the data copy program 24 processes ascheduled mirroring operation. A loop is performed at blocks 262 through268 for each data set entry 200 specified for the scheduled mirroringoperation. The data specified in the data set 202 for the entry 200,which may comprise database data 20, content 22 or data satisfying aquery defined for the mirroring operation, is accessed (at bock 264)from primary storage 18 and sent (at block 266) to each secondary server30 a, 30 b specified in the target server information 206.

At block 270, in response to receiving an update to data that is amember of a data set 202 specified in an entry 200 as having an highupdate frequency 204, such as “real-time”, control proceeds to block 272to determine the one or more secondary servers 30 a and 30 b specifiedin the target server information 206. The updates are then sent (atblock 274) to the determined secondary server(s) to apply to theattached secondary storage 32 a, 32 b.

With the logic of FIG. 4, updated data to the primary storage 18 ispropagated to the secondary storages according to an update frequencyspecified for the data. This allows updates to more critical data to beupdated immediately at the secondary storage, whereas less critical datathat does not change frequently may be updated with less frequency.Further, the data copy programs 34 a and 34 b at the secondary servers30 a and 30 b, respectively, would send any updates to the data at thesecondary storage 32 a, 32 b to the primary server 2. This allows theclients to update data at the secondary server to which they wereredirected.

In the logic of FIG. 4, the update frequency indicated a time intervalat which to propagate non-critical data to the secondary servers 30 aand 30 b. In alternative implementations, the update frequency maycomprise one or more threshold triggers other than a time interval. Forinstance, the update frequency may indicate a threshold percentage ofnon-critical data that has been modified, e.g., 10%, such that aftermodification of such threshold percentage of the non-critical data, theupdated non-critical data is propagated to the secondary servers 30 aand 30 b. Still further, the update frequency criteria may also indicatea threshold count of the number of updates to non-critical data, suchthat upon reaching the threshold count value, the modified non-criticaldata is propagated to the secondary servers 30 a and 30 b. Alternativeupdate frequency criteria may be applied in lieu of the time intervalfrequency described with respect to FIG. 4 or in addition to FIG. 4,such that the non-critical data is propagated to secondary sites uponthe occurrence of one or more triggering events, e.g., expiration of aspecified time interval, updating a threshold percentage of non-criticaldata, performing a threshold number of updates to non-critical data,etc. Different criteria may be maintained for different groups of thenon-critical data, i.e., different data sets 202 indicated in differententries 200 (FIG. 3).

FIG. 5 illustrates logic implemented in the data copy program 24 topropagate non-critical data when the update frequency 204 indicates atime interval, threshold percentage of updated non-critical data, and/ora threshold absolute number of updates to non-critical data. In thelogic of FIG. 5, each of these checks are described as being consideredtogether. However, in additional implementations, only one of thesechecks may be performed to determine when to propagate non-criticalcritical data, or any combination of the different checks may be used.Control begins at block 280 after propagating updates to non-criticaldata to the target server(s) 206. In response, a timer is cleared (atblock 282) that is used to determine when a time interval specified inthe update frequency 204 (FIG. 3) has expired, an update percentagecount is cleared (at block 284) indicating the percentage ofnon-critical data that has been updated, and an update count is cleared(at block 286) indicating the number of updates to non-critical datathat have been performed. Upon the occurrence of any one of the abovethresholds being satisfied at blocks 288, 290 or 292, the updatednon-critical data is then propagated (at block 294) to the one or moretarget servers 30 a and 30 b indicated in the target server field 206.

FIG. 6 illustrates logic implemented in the primary 2 and secondary 30a, 30 b servers to handle data requests from clients. Control begins atblock 300 with the primary HTTP server 4 receiving a request for datafrom a client 6 a, 6 b . . . 6 n, 10 a, 10 b . . . 10 n and determining(at block 302) a redirect secondary server 30 a, 30 b, and redirectingthe requesting client to that redirect secondary server. The HTTP server4 may use any criteria known in the art for selecting a secondary server30 a, 30 b as the redirect server. In certain implementations, the HTTPserver 4 may select the secondary server 30 a, 30 b that is within thedefined location of the client, e.g., client 6 a, 6 bn . . . 6 nrequests are redirected to secondary server 30 a. Additionally, the HTTPserver 4 may perform load balancing to redirect the request to thesecondary server with the lowest current load, thereby minimizing serverload delays. Still further, the HTTP server 4 may apply a combination offactors, or any other redirection selection factors known in the art.

At block 310 in FIG. 6, one secondary server 30 a,30 b receives theredirected client request. FIG. 1 shows how client requests 50 a and 50b are redirected at path 52 a and 52 b to one secondary server 30 a and30 b, respectively. After redirection, the client may communicatedirectly with the secondary server 30 a and 30 b, as shown on paths 54 aand 54 b. If (at block 312) the requested data is not within thesecondary storage 32 a, 32 b, then the secondary server 30 a, 30 brequests (at block 314) the requested data from the primary server 2 andstores the returned data in the secondary storage 32 a, 32 b. From block314 or the yes branch of block 312, the requested data is returned (atblock 316) to the client initiating the request.

FIG. 7 illustrates logic implemented in the transaction code 37 a and 37b in the secondary servers 30 a, 30 b to process a redirectedtransaction request from a client 6 a, 6 n . . . 6 n, 10 a, 10 b . . .10 n. Control begins at block 320 upon the HTTP server 36 a, 36 b in onesecondary server 30 a, 30 b receiving a redirected transaction requestfrom the client, such as a request to purchase or procure goods orservices. If (at block 322) the location database data 38 a, 38 bindicates that the requesting client is not registered, then thetransaction code 37 a, 37 b transmits (at block 324) a registration pageto the client 6 a, 6 b . . . 6 n, 10 a, 10 b . . . 10 n requesting theclient to register. Upon receiving the returned client registrationinformation, the transaction code 37 a, 37 b updates (at block 326) thelocation database data 38 a, 38 b with the new client registrationinformation and then sends the new client registration information tothe primary server 2. The primary server 2 would then propagate thereceived client registration information to the other secondary serversso all remote sites maintain consistent information. The locationdatabase data 38 a, 38 b may include different database tables, such asa customer registration table including information on a registeredcustomer, such as address, billing, and credit card information, tablesincluding information on product pricing and inventory. As discussed,the information in the location database data 38 a, 38 b may be specificto the location, such as all customers within the defined location.

If (at block 322) the requesting client is registered, then thetransaction code 37 a, 37 b generates (at block 328) a transactionobject and assigns a unique identifier (ID) to the transaction. Thetransaction object may comprise a record in a database table providinginformation on a client transaction prior to finalization or some datastructure maintaining information on a client initiated transaction.Additionally, in workflow processing environments, such as the IBMMQSeries** workflow environment, the transaction may comprise a piece ofworkflow that is processed at different nodes in a workflow managementscheme. At block 330, the transaction code 37 a, 37 b receives selectionof items for the transaction from the client, e.g., selected goods andservices. If (at block 332) the location database data 38 a, 38 bindicates that the selected items are not available, i.e., not incurrent inventory or unable to be provided, then the transaction code 37a, 37 b returns (at block 334) a message to the requesting client thatthe requested items are unavailable. At this time, the requesting clientmay be provided the option to backorder the items. If (at block 332) therequested items are available, then indication of the items are added(at block 336) to the transaction, i.e., transaction object or databaserecord.

The transaction code 37 a, 37 b then accesses (at block 338) clientcustomer information and accesses (at block 340) pricing information forthe selected product from the location database data 38 a, 38 b orcontent 40 a, 40 b and then generates (at block 342) a transactionapproval page for the client including the unique transaction ID,customer information, selected transaction items, cost of selecteditems, and a request for selection of a payment method. The transactionapproval page is returned to the client 6 a, 6 b . . . 6 n, 10 a, 10 b .. . 10 n. In alternative implementations, different types of informationmay be included in the pages transmitted to the application toaccomplish the transaction.

FIG. 8 illustrates logic implemented in the secondary and primary servertransaction code 5, 37 a, 37 b to process a client approval of atransaction. Control begins at block 350 with the secondary servertransaction code 37 a, 37 b receiving acceptance from a transactionapproval form sent to a requesting client. The transaction code 37 a, 37b then begins (at block 352) a process to approve the transaction byverifying data from the location database data 38 a, 38 b and obtainapproval from the credit card issuer for the transaction. As mentioned,the processing may be implemented by a workflow model. If (at block 354)the transaction is not approved, then a disapproved message is returnedto the client, perhaps stating the reason for the disapproval, e.g.,failure of credit card authorization. If the transaction is approved,then the secondary server transaction code 37 a, 37 b sends (at block358) the transaction information to the primary server 2 to finallyapprove of the transaction.

At block 360, the primary server transaction code 5 receives the requestto approve the transaction and transaction information from thesecondary server 30 a, 30 b. In response, the primary server transactioncode 5 processes (at block 362) the primary database data 20 to verifythe availability of the items included in the transaction and thecustomer information. In certain implementations, the payment or creditcard approval may be performed at the primary server and not thesecondary server as shown in FIG. 8. If (at block 364) all transactioninformation is consistent with the information maintained in the primarydatabase data 20, then the primary server transaction code 5 initiates(at block 366) a process to carry out the transaction, such as startinga workflow to execute the transaction, gather the transacted items, shipthe items, and bill the customer's credit card. The primary servertransaction code 5 returns (at block 368) approval to the secondaryserver 30 a, 30 b submitting the approval request. In response to thereceived approval, the secondary server transaction code 37 a, 37 breturns (at block 380) a page or message to the requesting client thatthe transaction was approved.

If (at block 364) the primary server transaction code 5 determined thatsome of the received transaction information is not consistent with thedata in the primary storage 18, then the transaction code 5 wouldgenerate and transmit (at block 380) a message to the secondary server30 a, 30 b that the data was not verified and include the data from theprimary site that is inconsistent with the data gathered from thesecondary storage 32 a, 32 b. In response to receiving the message, thesecondary server transaction code 37 a, 37 b would update (at block 382)the location database data 38 a, 38 b and/or content 40 a, 40 b with thedata received from the primary server 2. The transaction code 37 a, 37 bwould then generate and transmit (at block 384) a revised transactionapproval page to the client 6 a, 6 b . . . 6 n, 10 a, 10 b . . . 10 nincluding previous transaction data updated with new information fromthe primary storage 18 that was inconsistent with the data previouslyincluded in the transaction, for instance any price change informationor customer billing or contact information, product information, etc.Control would then return to block 350 to await the client's acceptanceof the revised transaction.

With the described implementations, most of the parts of a transactionand most data verification and gathering occurs at a remote secondaryserver from data mirrored for that location in the secondary storage.Ths architecture improves response times to client requests by reducingthe transmission distance of the requests because the client isredirected to communicate with a more geographically proximate serverand by redistributing the load from the primary server to remotesecondary servers. Moreover, in certain implementations, data ispropagated to the secondary servers in a manner that provides thesecondary sites with data in a timely manner and conserves networkbandwidth. This is accomplished by propagating updates to critical data,such as customer information, payment information, inventoryinformation, etc., at a high frequency, such as real time, andpropagating updates to data that changes less frequently at greaterintervals.

Still further, with the described implementations, data and transactionconsistency is maintained because final approval of the transaction isobtained from a primary storage site, which includes the most recentversion of data and ensures that a transaction processed at a secondarysite is not based on stale or inconsistent data.

Additional Implementation Details

The described data mirroring and transaction techniques may beimplemented as a method, apparatus or article of manufacture usingstandard programming and/or engineering techniques to produce software,firmware, hardware, or any combination thereof. The term “article ofmanufacture” as used herein refers to code or logic implemented inhardware logic (e.g., an integrated circuit chip, Programmable GateArray (PGA), Application Specific Integrated Circuit (ASIC), etc.) or acomputer readable medium (e.g., magnetic storage medium (e.g., hard diskdrives, floppy disks,, tape, etc.), optical storage (CD-ROMs, opticaldisks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs,ROMs, PROMs, RAMs, DRAMs, SRAMs, firmware, programmable logic, etc.).Code in the computer readable medium is accessed and executed by aprocessor. The code in which preferred embodiments are implemented mayfurther be accessible through a transmission media or from a file serverover a network. In such cases, the article of manufacture in which thecode is implemented may comprise a transmission media, such as a networktransmission line, wireless transmission media, signals propagatingthrough space, radio waves, infrared signals, etc. Of course, thoseskilled in the art will recognize that many modifications may be made tothis configuration without departing from the scope of the presentinvention, and that the article of manufacture may comprise anyinformation bearing medium known in the art.

The messages and information returned to the clients in response totransaction related requests may comprise pages, such as HTML or XMLpages transmitted using the HTTP protocol or comprise e-mail messages orinstant messaging messages.

In the described implementations one instance of a primary server andprimary storage is shown. In further implementations, the primary sitemay comprise multiple primary servers and primary storages. In certainimplementations, two secondary storage sites are shown each includingone secondary server and secondary storage. In further implementations,there may be more than two secondary storage sites at differentgeographical locations and each site may include multiple secondaryservers and/or secondary storages.

The preferred logic of FIGS. 4-8 described specific operations occurringin a particular order. Further, the steps may be performed in parallelas well as sequentially. In alternative embodiments, certain of thelogic operations may be performed in a different order, modified orremoved and still implement preferred embodiments of the presentinvention. Morever, steps may be added to the above described logic andstill conform to the preferred embodiments. Yet further, steps may beperformed by a single processing unit or by distributed processingunits.

In the described implementations, the transaction initiated by theclient comprised a transaction to purchase goods or services from acommercial retailer e-commerce web site. In alternative implementations,the transactions processed in the manner described above may compriseany type of transaction requesting resources or interactions that aclient would transmit across a network. Thus, the describedimplementations are not limited to commercial e-commerce type operationsand may encompass any network transaction known in the art that isserviced from a server.

In certain implementations, the distributed systems communicated acrossthe networks using the HTTP protocol for transmitting documents betweencomputers within a network. However, those skilled in the art willappreciate that any communication protocol may be used to transmitinformation in accordance with implementations of the invention.

In certain implementations, the secondary servers transmitted pages ofdata to the clients in the HTML or XML file format. However, anydocument or data format known in the art may be used to transmitinformation between the systems.

The foregoing description of the described implementations has beenpresented for the purposes of illustration and description. It is notintended to be exhaustive or to limit the invention to the precise formdisclosed. Many modifications and variations are possible in light ofthe above teaching. It is intended that the scope of the invention belimited not by this detailed description, but rather by the claimsappended hereto. The above specification, examples and data provide acomplete description of the manufacture and use of the composition ofthe invention. Since many embodiments of the invention can be madewithout departing from the spirit and scope of the invention, theinvention resides in the claims hereinafter appended.

1. A method for processing a transaction, comprising: transmittingtransaction data from one primary storage site to a plurality ofsecondary storage sites; receiving a transaction request at onesecondary storage site; processing the transaction request at thesecondary storage site to include transaction data from the secondarystorage site that was transmitted from the primary storage site;transmitting the processed transaction request including transactiondata from the secondary storage site to the primary storage site toapprove the transaction; and approving the transaction request at theprimary storage site if the transaction data included in the receivedtransaction request is consistent with the transaction data maintainedat the primary storage site.
 2. The method of claim 1, furthercomprising: receiving the transaction request at the primary storagesite; determining one secondary storage site from the plurality ofsecondary storage sites; and redirecting the transaction request to thedetermined secondary storage site, wherein the redirected transactionrequest comprises the transaction request received at the secondarystorage site.
 3. The method of claim 2, wherein determining onesecondary storage site from the plurality of secondary storage sitescomprises determining one available secondary storage site in closestproximity to a client originating the transaction request.
 4. The methodof claim 1, wherein the transaction request received at the secondarystorage site comprises a request to access resources, furthercomprising: determining from the transaction data at the secondarystorage site that was transmitted from the primary storage site whethera client originating the transaction request is registered, wherein thetransaction request is only processed if the client is registered. 5.The method of claim 1, wherein the transaction request received at thesecondary storage site comprises a request to access resources, furthercomprising: determining from the transaction data at the secondarystorage site that was transmitted from the primary storage site whetherthe requested resource is available; and returning a message indicatingthat the requested resource is not available if the transaction data atthe secondary storage site indicates that the requested resource is notavailable.
 6. The method of claim 1, wherein the transaction requestreceived at the secondary storage site comprises a request to purchase aproduct, further comprising: determining from the transaction data atthe secondary storage site that was transmitted from the primary storagesite pricing information for the requested product; generating at thesecondary storage site a response to return to a client originating thetransaction request indicating the pricing information for the requestedproduct; and transmitting the generated response to the client.
 7. Themethod of claim 6, further comprising: receiving acceptance of thetransaction from the client in response to the transmitted response,wherein the processed transaction request including the transaction datais transmitted from the secondary storage site to the primary storagesite after receiving acceptance of the transaction from the client. 8.The method of claim 6, further comprising: processing a payment methodfor the client after receiving the acceptance of the transaction toobtain approval of payment of the requested product, wherein thetransaction request is transmitted to the primary storage afterapproving the payment.
 9. The method of claim 8, wherein approving thetransaction request at the primary storage site further comprises:processing a payment method for the client after receiving thetransaction request from the secondary storage site.
 10. The method ofclaim 1, wherein if the transaction request is not approved at theprimary site, further comprising: transmitting from the primary storagesite to the secondary storage site transaction data that is notconsistent with the corresponding transaction data in the secondarystorage site; generating at the secondary storage site a revisedtransaction request including data transmitted from the primary storagesite that was not consistent in the secondary storage site; andtransmitting the revised transaction request to the client originatingthe transaction request for approval.
 11. The method of claim 1, whereindata transmitted to each secondary storage site is specific to ageographical location including the secondary storage site, such thatthe secondary storage sites receive different data from the primarystorage site.
 12. A system for processing a transaction, comprising:means for transmitting transaction data from one primary storage site toa plurality of secondary storage sites; means for receiving atransaction request at one secondary storage site; means for processingthe transaction request at the secondary storage site to includetransaction data from the secondary storage site that was transmittedfrom the primary storage site; means for transmitting the processedtransaction request including transaction data from the secondarystorage site to the primary storage site to approve the transaction; andmeans for approving the transaction request at the primary storage siteif the transaction data included in the received transaction request isconsistent with the transaction data maintained at the primary storagesite.
 13. The system of claim 12, further comprising: means forreceiving the transaction request at the primary storage site; means fordetermining one secondary storage site from the plurality of secondarystorage sites; and means for redirecting the transaction request to thedetermined secondary storage site, wherein the redirected transactionrequest comprises the transaction request received at the secondarystorage site.
 14. The system of claim 13, wherein the transactionrequest received at the secondary storage site comprises a request topurchase a product, further comprising: means for determining from thetransaction data at the secondary storage site that was transmitted fromthe primary storage site pricing information for the requested product;means for generating at the secondary storage site a response to returnto a client originating the transaction request indicating the pricinginformation for the requested product; and means for transmitting thegenerated response to the client.
 15. The system of claim 13, furthercomprising: means for receiving acceptance of the transaction from theclient in response to the transmitted response, wherein the processedtransaction request including the transaction data is transmitted fromthe secondary storage site to the primary storage site after receivingacceptance of the transaction from the client.
 16. The system of claim12, further comprising means for performing if the transaction requestis not approved at the primary site the steps of: transmitting from theprimary storage site to the secondary storage site transaction data thatis not consistent with the corresponding transaction data in thesecondary storage site; generating at the secondary storage site arevised transaction request including data transmitted from the primarystorage site that was not consistent in the secondary storage site; andtransmitting the revised transaction request to the client originatingthe transaction request for approval.
 17. The system of claim 12,wherein data transmitted to each secondary storage site is specific to ageographical location including the secondary storage site, such thatthe secondary storage sites receive different data from the primarystorage site.
 18. An article of manufacture including code at a primarystorage site and secondary storage sites for processing a transaction,wherein the code causes operations to be performed, the operationscomprising: transmitting transaction data from one primary storage siteto a plurality of secondary storage sites; receiving a transactionrequest at one secondary storage site; processing the transactionrequest at the secondary storage site to include transaction data fromthe secondary storage site that was transmitted from the primary storagesite; transmitting the processed transaction request includingtransaction data from the secondary storage site to the primary storagesite to approve the transaction; and approving the transaction requestat the primary storage site if the transaction data included in thereceived transaction request is consistent with the transaction datamaintained at the primary storage site.
 19. The article of manufactureof claim 18, further comprising: receiving the transaction request atthe primary storage site; determining one secondary storage site fromthe plurality of secondary storage sites; and redirecting thetransaction request to the determined secondary storage site, whereinthe redirected transaction request comprises the transaction requestreceived at the secondary storage site.
 20. The article of manufactureof claim 19, wherein determining one secondary storage site from theplurality of secondary storage sites comprises determining one availablesecondary storage site in closest proximity to a client originating thetransaction request.
 21. The article of manufacture of claim 18, whereinthe transaction request received at the secondary storage site comprisesa request to purchase a product, further comprising: determining fromthe transaction data at the secondary storage site that was transmittedfrom the primary storage site pricing information for the requestedproduct; generating at the secondary storage site a response to returnto a client originating the transaction request indicating the pricinginformation for the requested product; and transmitting the generatedresponse to the client.
 22. The article of manufacture of claim 21,further comprising: receiving acceptance of the transaction from theclient in response to the transmitted response, wherein the processedtransaction request including the transaction data is transmitted fromthe secondary storage site to the primary storage site after receivingacceptance of the transaction from the client.
 23. The article ofmanufacture of claim 18, wherein if the transaction request is notapproved at the primary site, further comprising: transmitting from theprimary storage site to the secondary storage site transaction data thatis not consistent with the corresponding transaction data in thesecondary storage site; generating at the secondary storage site arevised transaction request including data transmitted from the primarystorage site that was not consistent in the secondary storage site; andtransmitting the revised transaction request to the client originatingthe transaction request for approval.
 24. The article of manufacture ofclaim 18, wherein data transmitted to each secondary storage site isspecific to a geographical location including the secondary storagesite, such that the secondary storage sites receive different data fromthe primary storage site.